System and method for sharing san storage

ABSTRACT

According to various embodiments, systems and methods are provided that relate to shared access to Storage Area Networks (SAN) devices. In one embodiment, a Storage Area Network (SAN) host is provided, comprising: a server component: a first host bus adapter configured to be connected to a SAN client over a first SAN; a second host bus adapter configured to be connected to a SAN storage device over a second SAN; and wherein the server component is configured to manage a data block on the SAN storage device, receive a storage operation request from the SAN client through the first host bus adapter, and in response to the storage operation request, perform a storage operation on the data block, the storage operation being performed over the second SAN through the second host bus adapter.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication are hereby incorporated by reference under 37 CFR 1.57. Thisapplication is a division of U.S. patent application Ser. No.13/010,694, filed Jan. 20, 2011, entitled “SYSTEM AND METHOD FOR SHARINGSAN STORAGE”, which is herein incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to data storage, and moreparticularly, some embodiments relate to Storage Area Network (SAN)systems and methods.

2. Description of the Related Art

The storage and retrieval of data is an age-old art that has evolved asmethods for processing and using data have evolved. In the early 18thcentury, Basile Bouchon is purported to have used a perforated paperloop to store patterns used for printing cloth. In the mechanical arts,similar technology in the form of punch cards and punch tape were usedin the 18th century in textile mills to control mechanized looms. Twocenturies later, early computers also used punch cards and paper punchtape to store data and to input programs.

However, punch cards were not the only storage mechanism available inthe mid 20th century. Drum memory was widely used in the 1950s and 1960swith capacities approaching about 10 kb, and the first hard drive wasdeveloped in the 1950s and is reported to have used 50 24-inch discs toachieve a total capacity of almost 5 MB. These were large and costlysystems and although punch cards were inconvenient, their lower costcontributed to their longevity as a viable alternative.

In 1980, the hard drive broke the 1 GB capacity mark with theintroduction of the IBM 3380, which could store more than two gigabytesof data. The IBM 3380, however, was about as large as a refrigerator,weighed ¼ ton, and cost between approximately $97,000 to $142,000,depending on features selected. In contrast, contemporary storagesystems now provide storage for hundreds of terabytes of data, or more,for seemingly instantaneous access by networked devices. Even handheldelectronic devices such as digital cameras, MP3 players and others arecapable of storing gigabytes of data, and modern desktop computers boastgigabytes or terabytes of storage capacity.

With the advent of networked computing, storage of electronic data hasalso expanded from the individual computer to network-accessible storagedevices. These include, for example, optical libraries, Redundant Arraysof Inexpensive Disks (RAID), CD-ROM jukeboxes, drive pools and othermass storage technologies. These storage devices are accessible to andcan be shared by individual computers using such traditional networks asLocal Area Networks (LANs) and Wide Area Networks (WANs), or usingStorage Area Networks (SANs). These client computers not only accesstheir own local storage devices but also network storage devices toperform backups, transaction processing, file sharing, and otherstorage-related operations.

Network bandwidth is limited and can be overloaded by volumes of datastored and shared by networked devices. During operations such as systembackups, transaction processing, file copying and transfer, and othersimilar operations, the network communication bandwidth often becomesthe rate-limiting factor.

SANs, in particular, are networks designed to facilitate transport ofdata to and from network storage devices, while addressing the bandwidthissues caused by large volumes of data stored and shared on the networkstorage devices. Specifically, SANs are network architectures thatcomprise a network of storage devices that are generally not accessibleby nodes on a traditional network (e.g., LAN or WAN). As such, a SANimplementation usually requires two networks. The first network is atraditional network, such as a LAN, designed to transport ordinarytraffic between individual network computers (i.e., nodes). The secondnetwork is the SAN itself, which is accessible by individual computersthrough the SAN but not through the traditional network. Typically, oncea SAN storage device (also referred to as a SAN storage node) isremotely attached to an individual computer over a SAN, it appears andfunctions much like a locally attached storage device (as opposed toappearing and functioning as a network drive).

By utilizing a SAN as a separate network for storage devices thatperform bandwidth-intensive operations (e.g., backups, transactionprocessing, and the like), the SAN storage devices realize improvedbandwidth among themselves and with traditional computers attached tothe SAN. Additionally, when storage devices and traditional nodescommunicate over the SAN, more bandwidth-intensive operations areperformed over the SAN rather than a LAN, leaving the LAN to handle onlythe ordinary data traffic.

FIG. 1 illustrates an example of a traditional SAN implementation 10.There are multiple client nodes 15, 18, and 21 networked together usinga LAN 1 which allows communication of ordinary data traffic between thenodes (15, 18, 21). Storage devices 12 are connected together throughSAN 13, which provides high bandwidth network capacity forbandwidth-intensive data operations to and from the storage devices 12.As illustrated, client nodes 18 and 21 are also connected to SAN 13,allowing them high bandwidth data access to the storage devices 12. Asdiscussed above, by utilizing the SAN to perform high bandwidth dataaccess, the client nodes are not only moving bandwidth-intensive dataoperations from the LAN 19 to the SAN 13, but also accessing the data athigher data rates than are typically available on a traditional networksuch as LAN. Typically, SANs utilize high bandwidth networktechnologies, such as Fiber Channel (FC), InfiniBand, Internet SmallComputer System Interface (iSCSI), HyperSCSI, and Serial Attached SCSI(SAS), which are not commonly utilized in traditional networks such asLANs.

SUMMARY OF THE INVENTION

Various embodiments of the invention relate to shared access to StorageArea Networks (SAN) storage devices, such as disk arrays, tapelibraries, or optical jukeboxes. Embodiments of the present inventionallow for managed, shared access to SAN storage devices while ensuringthat data to and from SAN storage devices traverses over the SAN, andnot traditional networks such as LANs or WANs. Embodiments of thepresent invention can also provide traditional client nodes withdynamic/on-demand provisioning of storage on SAN storage devices, andwith concurrent read/write access to SAN storage devices.

In one embodiment, a Storage Area Network (SAN) host is provided,comprising: a server component; a first host bus adapter configured tobe connected to a SAN client over a first SAN; a second host bus adapterconfigured to be connected to a SAN storage device over a second SAN;and wherein the server component is configured to manage a data block onthe SAN storage device, provide the SAN client with block access to thedata block on the SAN storage device, receive a storage operationrequest from the SAN client through the first host bus adapter, and inresponse to the storage operation request, perform a storage operationon the data block, the storage operation being performed over the secondSAN through the second host bus adapter. By providing the block accessto the SAN storage device, the SAN host can appear to the SAN client asa locally attached storage device. The SAN client may then access datamade available from the SAN storage device by the SAN host as if the SANclient has direct disk access to the SAN storage device.

For some embodiments, the first host bus adapter is configured toprovide the SAN client with block access to data on the SAN storagedevice through the first host bus adapter, while the second host busadapter is configured to provide the SAN host with block access to dataon the SAN storage device through the second host bus adapter.

In some embodiments, the first host bus adapter connects to the SANclient through the first host bus adapter using Fiber Channel (FC),InfiniBand, or Serial Attached SCSI (SAS). In additional embodiments,the second host bus adapter connects to the SAN storage device throughthe second host bus adapter using Fiber Channel (FC), InfiniBand, orSerial Attached SCSI (SAS). Additionally, in some embodiments, the firsthost bus adapter may be in target mode, so that the host bus adapter mayoperate as a server of data, while the second host bus adapter may be ininitiator mode, so that the second host bus adapter may operate as aclient of data.

In further embodiments, the server component is configured to manageshared access to one or more SAN storage devices. This shared accessmanagement may be performed by way of a data repository that the servercomponent utilizes to track and maintain one or more SAN storage deviceswithin a pool of storage resources. As this tracking and maintenance mayinvolve managing blocks of data within the pool of storage resources, inthe some embodiments the repository is utilized to manage the blocks ofdata on one or more SAN storage devices. Additionally, the servercomponent may use the data repository to provision and determineallocation of storage space within the pool to a client node. Further,the server component may be configured to perform dynamic/on-demandprovisioning of storage space on the SAN storage device for the SANclient as requested.

In some embodiments, the SAN storage device comprises a plurality of SANstorage devices managed by the server component as a pool of storageresources. In some such embodiments, the server component is furtherconfigured to add a new SAN storage device to the pool when the new SANstorage device is added to the second SAN.

In further embodiments, the server component may be further configuredto perform data de-duplication on the SAN storage device whileperforming a storage operation.

By managing shared access, the server component is able to operate as anarbitrator of storage operation requests it receives. As such, in someembodiments, the server component determine whether the storageoperation request is performed as the storage operation, and when thestorage operation request is performed as the storage operation. Thisdetermination, for example, may be performed based on one or moresettings and parameters stored on the SAN host system. Depending on theembodiment, the settings and parameters may be stored in and retrievedfrom a data repository accessible to the server component.

Additionally, the server component may configured to provide a pluralityof SAN clients with concurrent access to the SAN storage. As such, theserver component may be configured to arbitrate between a plurality ofstorage operation requests when they are received, either from a singleSAN client or from multiple SAN clients.

Depending on the embodiment, the first storage operation or the secondstorage operation may be a file read, a file write, a file create, or afile delete operation. Depending on the embodiment, the first storageoperation may be a discovery request to the system.

In additional embodiments, a Storage Area Network (SAN) client isprovided, comprising: a client component; a host bus adapter configuredto be connected to a SAN host over a first SAN; wherein the clientcomponent is configured to receive from the SAN client a request toperform a first storage operation on a SAN storage device, translate thefirst storage operation to a SAN host storage operation request, andsend the SAN host storage operation request to the SAN host over thefirst SAN, the SAN host being configured to receive the storageoperation request, and in response to the storage operation request,perform a second storage operation on the SAN storage device over asecond SAN. The host bus adapter of the SAN client may be set toinitiator mode. In some such embodiments, the client component receivesthe request to perform first storage operation through an applicationprogram interface (API) function call.

In some embodiments, a method for a Storage Area Network (SAN) host isprovided, comprising: receiving from a SAN client a request to perform afirst storage operation on a SAN storage device, wherein the request isreceived over a first SAN through a first host bus adapter; and inresponse to the request, performing a second storage operation on theSAN storage device, wherein the second storage operation is performedover a second SAN through a second host bus adapter. In some suchembodiments, the method further comprises: arbitrating between aplurality of storage operation requests. In additional such embodiments,the method further comprises: detecting a new SAN device on the secondSAN; and adding the new SAN storage to a pool of storage resources. Inother such embodiments, the method further comprises: receiving adiscovery request from the SAN client; and transmitting a discoveryresponse to the SAN client, wherein the discovery response representsthe SAN host as a traditional SAN storage device.

In yet further embodiments, a Storage Area Network (SAN) system isprovided, the system comprising a SAN host in accordance with anembodiment of the present invention, and a SAN client in accordance withan embodiment of the present invention. Other features and aspects ofthe invention will become apparent from the following detaileddescription, taken in conjunction with the accompanying drawings, whichillustrate, by way of example, the features in accordance withembodiments of the invention. The summary is not intended to limit thescope of the invention, which is defined solely by the claims attachedhereto.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention, in accordance with one or more variousembodiments, is described in detail with reference to the followingFigure. The drawings are provided for purposes of illustration only andmerely depict typical or example embodiments of the invention. Thesedrawings are provided to facilitate the reader's understanding of theinvention and shall not be considered limiting of the breadth, scope, orapplicability of the invention. It should be noted that for clarity andease of illustration these drawings are not necessarily made to scale.

FIG. 1 is a diagram illustrating an example traditional Storage AreaNetwork (SAN).

FIG. 2 is a diagram illustrating example of data storage algorithms andarchitectures that can be used in conjunction with the systems andmethods in accordance with embodiments of the present invention.

FIG. 3 is a diagram illustrating an example SAN in accordance with oneembodiment of the present invention.

FIG. 4 is a diagram illustrating an example sequence of interactionsbetween entities of a SAN in accordance with one embodiment of thepresent invention.

FIGS. 5A and 5B are flowcharts of example methods in accordance withembodiments of the present invention.

FIG. 6 is a diagram illustrating an example computing system with whichaspects of the systems and methods described herein can be implementedin accordance with one embodiment of the present invention.

The Figures are not intended to be exhaustive or to limit the inventionto the precise form disclosed. It should be understood that theinvention can be practiced with modification and alteration, and thatthe invention be limited only by the claims and the equivalents thereof.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention relates to Storage Area Networks (SANs) and, moreparticularly, shared access to Storage Area Network (SAN) storagedevices. Particular embodiments of the present invention allow formanaged, shared access to SAN storage devices. Some such embodimentsensure that data to and from SAN storage devices traverses over the SAN,and remains off traditional networks such as LANs or WANs. Furtherembodiments can provide traditional client nodes with dynamic/on-demandprovisioning of storage on SAN storage devices, while providingconcurrent read/write access to SAN storage devices.

Depending on the embodiment, the shared and concurrent access maycomprise simultaneous access to the same block of data, the same file,the same SAN storage device, or the same allocation of located on SANstorage device or within a pool of SAN storage devices (i.e., storageresources). In some embodiments, the shared and concurrent access may beimplemented by way of a queue that is maintained and controlled by theserver component. In further embodiments, the concurrent access may beimplemented by way priority framework, whereby a first SAN client havinghigher priority access than a second SAN client may preempt data accessfrom that second SAN client, or preempt the second SAN position in aqueue.

Before describing the invention in detail, it is useful to describe afew example environments with which the invention can be implemented.The systems and methods described herein can be implemented using anumber of different storage architectures. One such exemplary storagearchitecture is described with reference to Figure

Turning now to Figure the example storage operation cell 50 shown inFIG. 2 may performs storage operations on electronic data such as thatin a computer network. As shown in this example, storage operation cell50 may generally include a storage manager 100, a data agent 95, a mediaagent 105, and a storage device 115. The storage operation cell 50 mayalso include components such as a client 85, a data or information store90, databases 110 and 111, jobs agent 120, an interface module 125, anda management agent 130. Each media agent 105 may control one orInput/Output (I/O) devices such as a Host Bus Adaptor (HBA) or othercommunications link for transferring data from client 85 to storagedevices 115. Such a system and elements thereof are exemplary of amodular backup system such as the CommVault® QiNetix system, and alsothe CommVault GALAXY® backup system, available from CommVault Systems,Inc. of Oceanport, N.J., and further described in U.S. Pat. Nos.7,035,880 and 7,620,710 each of which is incorporated herein byreference in its entirety.

A storage operation cell, such as cell 50, may generally includecombinations of hardware and software components associated withperforming storage operations on electronic data. Exemplary storageoperation cells according to embodiments of the invention may include,CommCells as embodied in the QNet storage management system and theQiNetix storage management system by CommVault Systems of Oceanport,N.J. According to some embodiments of the invention, storage operationcell 50 may be related to backup cells and provide some or all of thefunctionality of backup cells as described in U.S. Pat. No. 7,395,282,which is also incorporated by reference in its entirety. It should benoted, however, that in certain embodiments, storage operation cells mayperform additional types of storage operations and other types ofstorage management functions that are not generally offered by backupcells.

Turning now to FIG. 3, a diagram is provided illustrating an example SANsystem 200 implemented in accordance with certain embodiments of thepresent invention. The illustrated system 200 includes a first SAN 203,a second SAN 209, and a SAN host 206. The first SAN 203, using SANconnections 212, connects SAN clients 218 together and connects the SANclients 218 to the SAN host 206. A SAN client is any sort of computingdevice trying to access a SAN storage device. In the illustratedembodiment, the SAN clients 218 are desktop computers. Depending onembodiment, the SAN client 218 may be operating a media agent thatcontrols one or more input/output (I/O) devices such as a host busadapter (HBA) or other communication link for transferring data over SANconnections 212 on the first SAN 203. For example, the SAN client 218may be connected to the first SAN 203 using a Fiber Channel HBA and aFiber Channel connection. Using SAN connections 212, a SAN client 218 onthe first SAN 203 may, for example, transfer data to and from a SANstorage device on the first SAN 203 or on another SAN (e.g., second SAN209). For instance, the SAN client 218 may transfer data over the firstSAN 203 and through the SAN connections 212, to the second SAN 209 viathe illustrated SAN host 206.

It should be noted that references herein to data transfers should beunderstood to involve such storage operations as file creation, filedeletion, file read, and file write. Additionally, one of ordinary skillin the art would understand and appreciate that data transfers describedherein can be readily facilitated by other means of data operations inaddition to just file operations (such as database operations).

Continuing with reference to FIG. 3, SAN host 206 is shown comprising afirst host bus adapter (HBA) 230, which enables connections to SANclients 218 through the first SAN 203, and a second host bus adapter(HBA) 233, which enables connections to SAN storage devices 221 via thesecond SAN 209. In the illustrated configuration, the first SAN 203 andthe second SAN 209 are isolated from one another, thereby allowing theSAN host 206 to manage and control (e.g., arbitrate) shared access ofthe SAN storage devices 221 by the SAN clients 218. Both the first hostbus adapter 230 and the second host bus adapter 233 could utilizedifferent types of bus technologies to facilitate communication overtheir respective SANs. For example, either the first host bus adapter230 or the second host bus adapter 233 may utilize such networktechnologies as Fiber Channel (FC), InfiniBand, Internet Small ComputerSystem Interface (iSCSI), HyperSCSI, and Serial Attached SCSI (SAS). Thefirst host bus adapter 230 or the second host bus adapter may simply bea traditional network interface, which allows such technologies asInternet Small Computer System Interface (iSCSI), Fiber Channel overEthernet (FCoE), and ATA over Ethernet (AoE) to be utilized by SAN host206 over the SANs.

As illustrated, the second SAN 209 connects SAN storage devices 221together using SAN connections 215, and connects those SAN storagedevices 221 to the SAN host 206. Similar to SAN clients 218, the SANstorage devices 221 may control one or more input/output (I/O) devices,such as HBAs or other communication links, that allow them to connect tothe second SAN 209. The SAN storage devices 221 may use, for example,Fiber Channel HBA to connect to the second SAN 209. Using a SANconnection 215, a SAN storage device 221 may, for example, transfer datato and from a SAN client on the second SAN 209 or on another SAN (e.g.,first SAN 203). For instance, the SAN storage device 218 may transferdata over the second SAN 209 to the second SAN 209 via the illustratedSAN host 206.

In some embodiments, the SAN host 206 operates as a conduit throughwhich SAN clients 218, which may or may not be connected to atraditional network (e.g., LAN), can share access to one or more SANstorage devices 221 on a second SAN 209 over a first SAN 203. By doingso, such embodiments not only provide the SAN clients 218 shared dataaccess to the SAN storage devices, but also provide such shared accesswithout having to utilize a traditional network (e.g., LAN or WAN) orhaving the data leave a SAN. In effect, this allows sharing ofbandwidth-intensive data to remain on the SAN without burdening the SANclients traditional network (e.g., LAN or WAN).

The SAN host 206 may also function as a manager of storage operations,managing the blocks of data on one or more SAN storage devices. Asmanager, the SAN host 206 may also manage what storage operations are tobe performed on SAN storage devices in response to a storage operationrequest from a SAN client. For example, SAN host 206 may includecomponents that allow it to determine whether a storage operation shouldbe performed on the SAN storage devices, and when a storage operationshould be performed on the SAN storage devices. This managementfunctionality may be utilized when, for example, two or more SAN clientsare sharing access to a shared SAN storage device, and the SAN clientsrequest concurrent access to the shared SAN storage device or pool,concurrent access to the same data on the shared SAN storage device, orconcurrent access to the same allocation of storage space on the sharedSAN storage. In further examples, this concurrent access may be to apool of SAN storage devices rather than just a single SAN storagedevice. As such, the SAN host 206 may allow for concurrent shared accessto one or more SAN storages devices while preventing deadlocks.

The management functionality of the SAN host 206 may also allowarbitration of two or multiple storage operation requests that arrive atrelatively the same time, deciding which storage operation should beperformed first, for example, based on such parameters as priority ofthe storage operation request.

Additionally, as part of data management functionality, the SAN host 206may function to track and maintain one or more SAN storage devices as apool of (SAN) storage resources (i.e., storage pool). In doing so, SANhost 206 may be allowed to, for example, dynamically provision (i.e.,allocate) storage space from the pool for a given SAN client. Forexample, if the SAN host 206 were managing a pool of SAN storageresources totaling 5 TB in free space, and three SAN clients request 1TB each of storage space, rather than statically reserving 1 TB of spacewithin the pool to each of the SAN clients, the SAN host 206 can make adynamic allocation of 1 TB to each of the SAN clients. In doing so, theSAN host is capable of growing a SAN client's storage space allocationas requested (i.e., on-demand).

Further, by managing the SAN storage devices as a pool of SAN storageresources, the SAN host 206 can readily manage the addition of new SANstorage devices to the pool, thereby allowing the pool to growdynamically. Specifically, the storage pool may allow the SAN host 206to dynamically add or remove one or more SAN storage devices (e.g., 221)from the pool, thereby increasing or decreasing the overall pool size,at times without the SAN clients even being made aware of such changes.It should be noted that, for some embodiments, the SAN host 206 iscapable of managing and presenting dynamically allocated storage spacesas Logical Unit Numbers (LUNs).

In some embodiments, the dynamic (e.g., on-demand) provisioning (i.e.,allocation) of storage space on the pool of SAN storage resources andthe tracking and maintenance of the pool may be tied into the managementfunction. For example, if a SAN client is writing to the shared pool ofSAN storage resources and the pool reaches its capacity, the arbitratorcould deny performance of the SAN client's storage write request.

In some embodiments, the SAN host 206 may manage the pool of SAN storageresources by way of a data repository (i.e., data store), which assistsin the tracking and maintenance of the pool (e.g., tracking free storagespace, tracking occupied storage space) and the allocation of storagespace to SAN clients. In the illustrated embodiment, the tracking andmaintenance of the pool of SAN storage resources (and, thus, the SANstorage devices 1) by the SAN host 206 is facilitated through datarepository 236. Depending on the embodiment, the data repository 206 maybe implemented as a data store, such as a database. Additionally, SANhost 206 may utilize the data repository 206 to manage data blockswithin the storage pool. For example, management of data block mayentail tracking ownership of data blocks to specific SAN clients,tracking storage of file data blocks that span multiple SAN storagedevices (e.g., 221), tracking assignment of data blocks to specificallocated storage space, tracking occupied storage space within thestorage pool, and tracking free storage space within the storage pool.

Through data repository 236, SAN host 206 can not only track dynamicprovisioning and allocation of storage space within the storage pool toindividual computing devices but, depending on the embodiment, can alsodynamically add and remove SAN storage devices 1 from the storage pool.For example, when new SAN storage device is added to the second SAN 209,the SAN host 206 can add the new SAN storage device to the its storagepool. In some such embodiments, the SAN host 206 may perform thediscovery and addition of the SAN storage device 242 to the poolautomatically upon the addition of the SAN storage device 242 to thesecond SAN 209. For example, SAN host 206 may be configured to activelymonitor the second SAN 209 for the addition of any new SAN storagedevices, and add any such SAN storage device to the storage pool.

The SAN host 206 further comprises a server component 227. In someembodiments, the server component 227 is responsible for listening toand responding to storage operation requests it receives from the SANclients 218. For example, the server component 227 may receive a fileread, file write, file create, file delete storage operation requestfrom a SAN client 218 and, in response, perform a corresponding storageoperation on a SAN storage device 221 and may send a response back tothe SAN client, depending on the storage operation request. According toembodiments that manage the SAN storage devices 221 as a pool of SANstorage resources, the corresponding storage operation may involve theserver component 227 performing the storage operations on two or moreSAN storage devices 221 within the storage pool. For example, the datablocks of a file involved in an operation may span three SAN storagedevices 221 and, hence, in order to operate on the file, the SAN host206 must perform a storage operation on those three SAN storage devices221.

In some embodiments, the server component may also be configured toimplement data de-duplication operations on the SAN storage devices 1,thereby increasing the over storage capacity of the SAN storage devices1. For example, in particular embodiments, the data de-duplication maybe implemented in the server component such that de-duplication istransparent to the SAN clients 218 jointly accessing the SAN storagedevices 218. According to one embodiment, the deduplication may befacilitated through a hash table or other reference table that resideson the SAN host 206. The table references data that is shared amongstthe SAN storage devices 221 managed by the SAN host 206. When the SANhost 206 is transferring data to the SAN storage devices 221, the SANhost 206 can use the table in a deduplication algorithm to determine ifa data segment already exists on a SAN storage device 221. When itdetermines a copy already exists, the SAN host 206 may use the referenceto an allocation of an existing copy of the data segment in place of theactual segment of data. Other de-duplication methodologies may be alsoemployed by SAN host 206.

In some embodiments, when a client has data to transfer to or place inthe shared storage, that client can run a deduplication algorithm onsegments of the data and use its own representative instantiation of thereference table to determine whether the data segments already exist ina shared data store. Accordingly, for a given segment, the client candetermine whether to send the entire data segment to the shared storageor just send a reference or pointer or other information from thereference table if the segment is duplicative of what is already in thedata store. In a situation where the analyzed segment is not in the datastore, the client device can send the hash value or other referencetable information to the central storage (or other location maintainingthe main reference table) so that the primary reference table can beupdated with the information on the newly added segment.

Though not illustrated, the SAN clients 218 may comprise a clientcomponent that interfaces and interacts with the server component 227 ofthe SAN host 206 over the first SAN 203. For some embodiments, such aclient component allows for seamless and transparent control of storageoperations on the SAN storage devices 221 through the SAN host 206. Forexample, in some embodiments, the client component is able to receivefile operation function calls through an application program interface(API), and then translate those function calls into storage operationrequests for the SAN host 206 to perform. In this manner, the APIencapsulates interactions between the client component and the servercomponent, leaving the SAN client 218 unaware of the implementation ofthe SAN storage solution. Indeed, for some embodiments, the pool of SANstorage resources (e.g., SAN storage devices 221) appears as atraditional SAN storage device/resource. In this way, some embodimentsof the present invention can readily integrate into existing SANimplementations with minimal to no change to the SAN implementation.

FIG. 4 provides an example sequence of interactions 300 between entitiesof a SAN in accordance with one embodiment of the present invention.Turning now to FIG. 4, the sequence begins with the establishment 312 ofa Storage Area Network (SAN) connection between a SAN client 303 and aSAN host 306 over a first SAN, and the establishment 315 of a SANconnection between the SAN host 306 and a SAN storage device 309 over asecond SAN. Once the connections are established, SAN client 303performs a storage operation through an API function call. In someembodiments, the function call 321 instructs a client component residingon the SAN client 303 to transmit 324 to the SAN host 306 a storageoperation request corresponding to the API function call 1. The clientcomponent thereby performs a storage operation request on behalf of theSAN client 303. Additionally, by instructing the client componentthrough the API function call 32], the interactions between the SANclient 303 and SAN host 306 are encapsulated by the API. This easesintegration of some embodiments into existing SANs.

Upon receiving the request from the SAN client 303, the SAN host 306responds to the request, generally by sending one or more requests 327to the SAN storage device 309 over a second SAN, which may invoke one ormore responses 328 from the SAN storage device 309.

Subsequently, SAN host 306 may respond 330 to the SAN client 303 basedon the response 328 from the SAN storage device 309 or the originalrequest 324 from the SAN client. For example, where the SAN client 303instructs its client component to perform a file read operation throughan API, the client component would translate the instruction to a fileread storage operation request, which is subsequently sent to the SANhost 306 (e.g., 321). The SAN host 306, in response to the file readstorage operation request (e.g., 324), requests a file read operationfrom the SAN storage device 309 (e.g., 327), receives the file read datafrom the SAN storage device 309 (e.g., 328), and transmits that fileread data back to the SAN client (330) in response to the originalrequest (e.g., 324). In some embodiments, other storage operations, suchas file writes, file creates, and file deletes, could have similarinteraction flow.

Returning to Figure in some embodiments, the system 200 of FIG. 3 may beimplemented into storage operation cell 50 of FIG. 2. For example, inone embodiment, system 200 could be implemented such that: the client 85would operate as one of the SAN clients 218 of FIG. 3; the data agent 95would operate as the client component that interfaces with SAN host 206over a first SAN; the storage manager 100, media agents 105, and hostbus adapters (HBAs) 133 would collectively operate as SAN host 206 ofFIG. 3, where the storage manager 100 in conjunction with the mediaagents 105 would operate as the server component 227 of FIG. 3, and theHBAs 133 would operate as multiple second host bus adapters (233) ofFIG. 3; and storage devices 115 would operate as the SAN storage devicescommunicating with the HBAs 133 over a second SAN.

FIGS. 5A and 5B provides flowcharts of example methods in accordancewith embodiments of the present invention. Specifically, FIG. 5Aprovides a flowchart of method 400 of storage discovery operation inaccordance with an embodiment of the present invention, while FIG. 5Bprovides a flowchart of a method 450 for performing a general filestorage operation in another embodiment of the present invention.

Turning now to FIG. 5A, method 400 begins as operation 403 with a SANclient 218, 303) performing a discovery function call through an API.This causes the SAN client to send a discovery request to a SAN host atoperation 406. Depending on the embodiment, when the discovery functioncall is executed in operation 403, the API may instruct a clientcomponent residing on the SAN client to transmit a discovery request tothe SAN host in operation 406.

The SAN host, upon receiving the discovery request, may send a discoveryresponse back to the client at operation 409. Through the discoveryresponse, the SAN host may, for example, inform the client of itsstorage features or capabilities (e.g., available storage space, totalstorage space, occupied storage space). Additionally, some embodimentsmay respond to the client such that the SAN host appears as atraditional SAN storage device. Alternatively, in embodiments such asmethod 400, the client may interpret the discovery response from the SANhost (at operation 409) to be one from a traditional SAN storage device.

In alternative embodiments, the client, upon discovering the existenceof the SAN host and acquiring its SAN identifier (e.g., World Wide Namefor a Fiber Channel SAN), can send a discover request to the host busadapter of the SAN host. The SAN host, in response informs the clientregarding aspects of its storage, such as free storage space andoccupied space.

Turning now to FIG. 5B, method 450 for performing a general fileoperation in accordance with an embodiment is presented. Similar tomethod 400, method 450 begins as operation 453 with a SAN client (e.g.,218, 303) performing a file operation function call through an API,which causes the SAN client to send a file operation request to a SANhost at operation 456. In some embodiments, when the file operationfunction call is executed in operation 453, the API instructs a clientcomponent residing on the SAN client to transmit the file operationrequest to the SAN host in operation 456.

At operation 459, method 450 continues with the SAN host arbitrating if,when, and how the SAN host will perform the requested file operation.Based on the results of the operation 459, the method 450 may then senda response to the client at operation 462. For example, the client maybe requesting a file write to the SAN storage device, but may havealready exhausted its storage space allocation. As a result, the SANhost, functioning as arbitrator, may deny the client its file writerequest and, accordingly, send the client a file write denial (e.g., atoperation 462). Other embodiments may involve additional data operations(e.g., file reads, file creation, file deletion).

As used herein, the term module might describe a given unit offunctionality that can be performed in accordance with one or moreembodiments of the present invention. As used herein, a module might beimplemented utilizing any form of hardware, software, or a combinationthereof. For example, one or more processors, controllers, ASICs, PLAs,logical components, software routines or other mechanisms might beimplemented to make up a module. In implementation, the various modulesdescribed herein might be implemented as discrete modules or thefunctions and features described can be shared in part or in total amongone or more modules. In other words, as would be apparent to one ofordinary skill in the art after reading this description, the variousfeatures and functionality described herein may be implemented in anygiven application and can be implemented in one or more separate orshared modules in various combinations and permutations. Even thoughvarious features or elements of functionality may be individuallydescribed or claimed as separate modules, one of ordinary skill in theart will understand that these features and functionality can be sharedamong one or more common software and hardware elements, and suchdescription shall not require or imply that separate hardware orsoftware components are used to implement such features orfunctionality.

Where components or modules of the invention are implemented in whole orin part using software, in one embodiment, these software elements canbe implemented to operate with a computing or processing module capableof carrying out the functionality described with respect thereto. Onesuch example-computing module is shown in FIG. 6. Various embodimentsare described in terms of this example-computing module 500. Afterreading this description, it will become apparent to a person skilled inthe relevant art how to implement the invention using other computingmodules or architectures.

Referring now to FIG. 6, computing module 500 may represent, forexample, computing or processing capabilities found within desktop,laptop and notebook computers; hand-held computing devices (PDA's, smartphones, cell phones, palmtops, etc.); mainframes, supercomputers,workstations or servers; or any other type of special-purpose orgeneral-purpose computing devices as may be desirable or appropriate fora given application or environment. Computing module 500 might alsorepresent computing capabilities embedded within or otherwise availableto a given device. For example, a computing module might be found inother electronic devices such as, for example, digital cameras,navigation systems, cellular telephones, portable computing devices,modems, routers, W APs, terminals and other electronic devices thatmight include some form of processing capability.

Computing module 500 might include, for example, one or more processors,controllers, control modules, or other processing devices, such as aprocessor 504. Processor 504 might be implemented using ageneral-purpose or special-purpose processing engine such as, forexample, a microprocessor, controller, or other control logic. In theexample illustrated in FIG. 6, processor 504 is connected to a bus 502,although any communication medium can be used to facilitate interactionwith other components of computing module 500 or to communicateexternally.

Computing module 500 might also include one or more memory modules,simply referred to herein as main memory 508. For example, preferablyrandom access memory (RAM) or other dynamic memory might be used forstoring information and instructions to be executed by processor 504.Main memory 508 might also be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 504. Computing module 500 might likewise include aread only memory (“ROM”) or other static storage device coupled to bus502 for storing static information and instructions for processor 504.

The computing module 500 might also include one or more various forms ofinformation storage mechanism 510, which might include, for example, amedia drive 512 and a storage unit interface 520. The media drive 512might include a drive or other mechanism to support fixed or removablestorage media 514. For example, a hard disk drive, a floppy disk drive,a magnetic tape drive, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive might be provided.Accordingly, storage media 514, might include, for example, a hard disk,a floppy disk, magnetic tape, cartridge, optical disk, a CD or DVD, orother fixed or removable medium that is read by, written to or accessedby media drive 512. As these examples illustrate, the storage media 514can include a computer usable storage medium having stored thereincomputer software or data.

In alternative embodiments, information storage mechanism 510 mightinclude other similar instrumentalities for allowing computer programsor other instructions or data to be loaded into computing module 500.Such instrumentalities might include, for example, a fixed or removablestorage unit 522 and an interface 520. Examples of such storage units522 and interfaces 520 can include a program cartridge and cartridgeinterface, a removable memory (for example, a flash memory or otherremovable memory module) and memory slot, a PCMCIA slot and card, andother fixed or removable storage units and interfaces 520 that allowsoftware and data to be transferred from the storage unit to computingmodule 500.

Computing module 500 might also include a communications interface 524.Communications interface 524 might be used to allow software and data tobe transferred between computing module 500 and external devices.Examples of communications interface 524 might include a modem orsoftmodem, a network interface (such as an Ethernet, network interfacecard, Wi Media, IEEE 802.XX or other interface), a communications port(such as for example, a USB port, IR port, RS232 port Bluetooth®interface, or other port), or other communications interface. Softwareand data transferred via communications interface 524 might typically becarried on signals, which can be electronic, electromagnetic (whichincludes optical) or other signals capable of being exchanged by a givencommunications interface 524. These signals might be provided tocommunications interface 524 via a channel 528. This channel 528 mightcarry signals and might be implemented using a wired or wirelesscommunication medium. These signals can deliver the software and datafrom memory or other storage medium in one computing system to memory orother storage medium in computing system 500. Some examples of a channelmight include a phone line, a cellular link, an RF link, an opticallink, a network interface, a local or wide area network, and other wiredor wireless communications channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to physical storage mediasuch as, for example, memory 508, storage unit 520, and media 514. Theseand other various forms of computer program media or computer usablemedia may be involved in storing one or more sequences of one or moreinstructions to a processing device for execution. Such instructionsembodied on the medium, are generally referred to as “computer programcode” or a “computer program product” (which may be grouped in the formof computer programs or other groupings). When executed, suchinstructions might enable the computing module 500 to perform featuresor functions of the present invention as discussed herein.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not of limitation. Likewise, the various diagrams maydepict an example architectural or other configuration for theinvention, which is done to aid in understanding the features andfunctionality that can be included in the invention. The invention isnot restricted to the illustrated example architectures orconfigurations, but the desired features can be implemented using avariety of alternative architectures and configurations. Indeed, it willbe apparent to one of skill in the art how alternative functional,logical or physical partitioning and configurations can be implementedto implement the desired features of the present invention. Also, amultitude of different constituent module names other than thosedepicted herein can be applied to the various partitions. Additionally,with regard to flow diagrams, operational descriptions and methodclaims, the order in which the steps are presented herein shall notmandate that various embodiments be implemented to perform the recitedfunctionality in the same order unless the context dictates otherwise.

Although the invention is described above in terms of various exemplaryembodiments and implementations, it should be understood that thevarious features, aspects and functionality described in one or more ofthe individual embodiments are not limited in their applicability to theparticular embodiment with which they are described, but instead can beapplied, alone or in various combinations, to one or more of the otherembodiments of the invention, whether or not such embodiments aredescribed and whether or not such features are presented as being a partof a described embodiment. Thus, the breadth and scope of the presentinvention should not be limited by any of the above-described exemplaryembodiments.

Terms and phrases used in this document, and variations thereof, unlessotherwise expressly stated, should be construed as open ended as opposedto limiting. As examples of the foregoing: the term “including” shouldbe read as meaning “including, without limitation” or the like; the term“example” is used to provide exemplary instances of the item indiscussion, not an exhaustive or limiting list thereof; the terms “a” or“an” should be read as meaning “at least one,” “one or more” or thelike; and adjectives such as “conventional,” “traditional,” “normal,”“standard,” “known” and terms of similar meaning should not be construedas limiting the item described to a given time period or to an itemavailable as of a given time, but instead should be read to encompassconventional, traditional, normal, or standard technologies that may beavailable or known now or at any time in the future. Likewise, wherethis document refers to technologies that would be apparent or known toone of ordinary skill in the art, such technologies encompass thoseapparent or known to the skilled artisan now or at any time in thefuture.

The presence of broadening words and phrases such as “one or more,” “atleast,” “but not limited to” or other like phrases in some instancesshall not be read to mean that the narrower case is intended or requiredin instances where such broadening phrases may be absent. The use of theterm “module” does not imply that the components or functionalitydescribed or claimed as part of the module are all configured in acommon package. Indeed, any or all of the various components of amodule, whether control logic or other components, can be combined in asingle package or separately maintained and can further be distributedin multiple groupings or packages or across multiple locations.

Additionally, the various embodiments set forth herein are described interms of exemplary block diagrams, flow charts and other illustrations.As will become apparent to one of ordinary skill in the art afterreading this document, the illustrated embodiments and their variousalternatives can be implemented without confinement to the illustratedexamples. For example, block diagrams and their accompanying descriptionshould not be construed as mandating a particular architecture orconfiguration.

What is claimed is:
 1. A storage area network (SAN) client, comprising:a client component comprising one or more computer processors; and ahost bus adapter configured to be connected to a SAN host over a firstSAN, wherein the client component is configured to: receive from the SANclient a request to perform a first storage operation on a SAN storagedevice; translate the first storage operation to a SAN host storageoperation request; and send the SAN host storage operation request tothe SAN host over the first SAN, wherein the SAN host is configured toreceive the storage operation request, and in response to the storageoperation request, perform a second storage operation on the SAN storagedevice over a second SAN.
 2. The SAN client of claim 1 wherein the hostbus adapter connects to the SAN host over the first SAN using FiberChannel (FC), InfiniBand, or Serial Attached SCSI (SAS).
 3. The SANclient of claim 1 wherein the host bus adapter is in initiator mode. 4.The SAN client of claim 1 wherein the first storage operation or thesecond storage operation is a file read, a file write, a file create, ora file delete operation.
 5. The SAN client of claim 1 wherein the firststorage operation is a discovery request.
 6. The SAN client of claim 5wherein the client component is further configured to: receive adiscovery response from the SAN host indicating that the SAN host is atraditional SAN storage device; and interpret the discovery response. 7.The SAN client of claim 1 wherein the client component receives therequest to perform first storage operation through an applicationprogram interface (API) function call.
 8. A method of operating astorage area network (SAN) client, comprising: receiving with a clientcomponent of a SAN client a request to perform a first storage operationon a SAN storage device; translating with one or more processors of theclient component the first storage operation to a SAN host storageoperation request; and electronically sending the SAN host storageoperation request to the SAN host over the first SAN, wherein the SANhost is configured to receive the storage operation request, and inresponse to the storage operation request, perform a second storageoperation on the SAN storage device over a second SAN.
 9. The method ofclaim 8 wherein the host bus adapter connects to the SAN host over thefirst SAN using Fiber Channel (FC), InfiniBand, or Serial Attached SCSI(SAS).
 10. The method of claim 8 wherein the host bus adapter is ininitiator mode.
 11. The method of claim 8 wherein the first storageoperation or the second storage operation is a file read, a file write,a file create, or a file delete operation.
 12. The method of claim 8wherein said receiving is through an application program interface (API)function call.
 13. The method of claim 8 wherein the first storageoperation is a discovery request.
 14. The method of claim 13 furthercomprising: with the client component, receiving a discovery responsefrom the SAN host indicating that the SAN host is a traditional SANstorage device; and interpreting the discovery response with one or moreprocessors of the client component.